我有多年 IT 技術與跨域學習經驗，現在把 AI、Cloud、Infrastructure 串起來。

如果Docker Image 做好了，為什麼還不能直接上 Production？

前幾天一路從 AI Environment、Dependency、GPU Runtime 談到 Docker。當我終於可以把 AI Application 打包成 Container Image 後，很容易產生一個想法：

「現在應該可以直接部署了吧？」

但真正開始思考 Production 後，我發現 Container Image 只是把 Application 準備好了，並不代表服務已經準備好了。

如果今天只有自己測試，一個 Container 跑起來可能就夠了。但當真的有使用者開始呼叫 AI Service，就會出現新的問題：服務要放在哪裡？如果 Container 掛掉怎麼辦？同時有很多請求時怎麼處理？如果需要 GPU，哪一台機器應該執行它？更新版本時，又要怎麼避免整個服務中斷？

我自己一路從 Cloud、Docker 到 Kubernetes 的實作過程中，慢慢發現，「把程式跑起來」和「把服務部署起來」其實是兩種不同的工程問題。

Kubernetes 的 Deployment 就是其中一個重要概念：Kubernetes 官方把 Deployment 定義為管理 Pods 與 ReplicaSets、進行宣告式更新的機制，它可以描述應該執行多少個 Pod，以及如何更新這些應用程式實例；而在 GKE 的 AI inference 架構中，還需要進一步處理 Service、GPU、Scaling 與 Monitoring。另外，Google Cloud 現行 GKE AI 文件則把 AI inference deployment 拆成 Containerize model → build Cluster → Deployment → Service → Scaling/Monitoring。

所以問題來了：

如果 Docker 解決的是「我的 AI 可以被打包」，那麼誰負責讓這個 AI Service 持續、穩定地被使用者使用？

這也是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》接下來要從 Container 走向 Deployment 與 Kubernetes 所要回答的問題。例如：Docker 解決「如何把 Application 封裝與交付」，但 Production 還需要處理 Availability、Scaling、Networking、Resource Management、Updates、Monitoring…

關於作者

我是一名 AI × Infrastructure Solution / Integration 技術實作者，專注於 AI、MLOps、Cloud、Docker、Kubernetes、GPU、LLM 與 AI Agent 等技術的整合與落地，跨足 LLM、GPU、Docker、Kubernetes、MLOps 與 AI Agents，持續研究企業 AI 從 Prototype 到 Production 所需要的工程能力。協助企業理解 AI 從 Prototype 到 Production 所需要的技術能力。

本系列同時是《AI Infrastructure 實戰：AI Demo 為什麼上不了 Production？》的延伸實戰筆記。如果想完整理解這些更深的技術問題，未來可以去看這本書(書中包含了一些的範例與提示詞，特別是AMD W7900 48G的使用技術心得，這些是外面很少有的獨家踩坑經驗，未來買書真的賺到！)。敬請期待唷~ 關於永久網站也有了，正在準備了，很高興今天找到了設計師~